AUS920010792US1 

111 

Examples for Generating and Using Fragment Cache 
Identifiers 

As described above, caching information is 
associated with each fragment that instructs caches how 
to cache that fragment. For static content, caching 
information is associated with each fragment. Dynamic 
content is generated by a template or program (JSP, CGI, 
etc.), and caching information would be associated with 
this template. This could be constant information, so 
that all fragments generated by the template would have 
the same values. Alternatively, the template could have 
code that determines the caching information, so that it 
can be different for each generated fragment based on 
some algorithm. In either case, a specific fragment has 
constant values • 

A fragment can be defined as a portion of content 
that has been delimited for combination with another 
portion of content. A standardized fragment naming 
technique is used when implementing the present 
invention; the technique generates cache IDs in 
accordance with a technique that was described more 
formally above. This section describes the use of cache 
IDs through a series of examples further below, although 
a brief recap of the formation and determination of cache 
IDs is first provided. 

A cache stores the fragment using a cache ID in some 
manner. Enough information should be included in the 
cache ID to make it unique among all applications using 
the cache. For example, a product ID alone might collide 
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with another store's product ID or with something else 
entirely. Since the URI path for a fragment typically 
has to address this same name scoping problem at least in 
part, it is convenient to include the URI path as part of 
5 the cache ID for a fragment . 

The information content of a cache ID determines how 
widely or narrowly the fragment is shared, as shown in 
the following examples. 

(A) If a user ID is included in a cache ID, then the 
10 fragment is used only for that user. 
Hj (B) If a shopper group ID is included in a cache ID, 

Q then the fragment is shared across all members of that 

% shopper group. 

H (C) If no user ID or shopper group ID is included in 

5 15 a cache ID, then the fragment is shared across all users. 
« A Web application developer can specify the 

flj information content of a cache ID by a rule in the 

^J; fragment's HTTP FRAGMENT header with a CACHEID directive 

C that states what is included in the fragment's cache ID. 

20 A rule allows any URI query parameter or cookie to be 
appended to the URI path, or allows the full URI 
{including query parameters) . The absence of a rule 
means do not cache. When multiple rules are used, the 
rules are tried in order of appearance. The first rule 
25 that works determines the cache ID. If no rule works, 

then the fragment is not cached. When a query parameter 
or cookie is included in the cache ID, it can be either 
required or optional, as follows. 

(A) A required query parameter that is not present 
30 in the parent's request causes the rule to fail. 
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(B) A required cookie that is not present in the 
parent's request or in the result causes the rule to 
fail. 

(C) An optional query parameter or cookie that is 
5 not present is not included in the cache ID. 

A cache ID is case-sensitive except for those parts 
that some standard has declared case-insensitive. The 
HTTP specification states that a URI's protocol and host 
name are case- insensitive while the rest of the URI is 
y.lO case-sensitive including query parameter names. 
Q According to the specification ""HTTP State Management 
hi Mechanism'', RFC 2109, Internet Engineering Task Force, 

Ti February 1997, cookie names are case- insensitive . A 

4- cache implementation can easily enforce this by 
715 transforming these case insensitive parts to a uniform 

case. The fragment caching technique of the present 
M invention preferably makes query parameter values and 

S cookie values case- sensitive . 

P With reference now to Figures IIA-IIH, a series of 

20 diagrams are used to illustrate the manner in which the 
technique of the present invention constructs and uses 
unique cache identifiers for storing and processing 
fragments . 

Referring to Figure llA, all parent fragments at a 
25 site contain the same sidebar child fragment. The parent 
fragment is not specified in this scenario except that 
all parents contain the same sidebar fragment, so only 
the child fragment is at issue. The child fragment is 
logically qualified by its URI. 
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Since it is static content, its cache ID is the full URI . 
The cache ID rule would be: 

Fragment : cacheid= ''URI " 
In other words, the cache ID is the full URI including 
all query parameters. An example of the cache ID would 
be : 

http : //www. acmeStore . com/sidebar . html 
Referring to Figure IIB, a product description page 
contains no embedded or child fragments, i.e. the page is 
the only fragment. It is logically qualified by the 
product ID. The page URI has a product ID query parameter. 
The page request has an encrypted userlD cookie that is 
created by the Web application server during logon. The 
userlD cookie allows user-specific state (shopping cart, 
user profile, etc) to be associated with the user. The 
userlD is used as a cookie rather than a query parameter 
because it may be used with almost every request, and it 
would be tedious for the Web application developer to put 
it in every link. The single cache ID rule for the 
product page could use the full URI as the cache ID, 
which includes the product ID query parameter, so that it 
can be cached with the correct qualifications. For this 
single fragment page, the cache ID can be its URI. The 
cache ID rule would be: 

Fragment : cacheid=''URI" 

In other words, the cache ID is the full URI 
including all query parameters. An example of the cache 
ID would be: 

http : //www. acmeStore . com/productDesc . j sp?productID=A 
T13394 
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Another way to specify the cache ID for this 
top-level fragment is the product ID used by the 
merchant, e.g., AT13394, which is a URI query parameter, 
plus the constant URI path to ensure uniqueness, e.g., 
http://www.acmeStore.com/productDesc. In this case, the 
cache ID rule would be: 

Fragment : cacheid='' (product Id) " 
In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; and 

(B) the name and value of the product ID query 
parameter. 

The lack of square brackets in the rule indicates 
that the product ID parameter should exist. Otherwise, 
the rule fails, and the fragment will not be cached. An 
example of the cache ID would be: 

http : //www . acmes tore . com/productDesc . j sp_product ID=A 
T13394 

It should be noted again that the Web application 
developer specifies only the information content of a 
cache ID, not the exact format. The cache 
implementations can choose their own way to encode the 
specified information content in the cache ID. The above 
example uses simple concatenation with an underscore 
character as a separator delimiter. The Web 

application developer does not need to know this 
encoding. 

Referring to Figure IIC, an extension of the product 
description scenario is provided. The price is now 
determined by which shopper group in which the user 
belongs, but the rest of the product description is 
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independent of shopper group. A parent product 
description fragment contains a child price fragment. 
The parent is logically qualified by the product ID, The 
child is logically qualified by the productID and the 
5 groupID. The page URI has a productID query parameter. 
The page request has encrypted userlD and groupID 
cookies. The groupID cookie is created by the Web 
application during logon based on the user profile. The 
groupID is made a cookie rather than a query parameter 
10 because it may be used with almost every request, and it 
p would be tedious for the Web application developer to put 

it in every link. 
4« The price should be in a separate child fragment 

£ included by the parent. The single cache ID rule for the 

^^15 parent fragment would be the same as in the product 
%s display scenario. The single cache ID rule for the child 

fragment would use the URI path along with the productID 
query parameter and groupID cookie, so that it can be 
yi cached with the correct qualifications. It should be 

20 noted that the cache ID does not include user ID because 
then the fragment could only be used by a single user 
instead of all users belonging to the same shopper group, 
thereby resulting in a much larger cache and more work to 
keep the cache updated. The cache ID rule would be: 
25 Fragment: cacheid='' (productID, [groupID] ) " 

In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; 

(B) the name and value of the productID query 
30 parameter; and 
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(C) the name and value of the groupID cookie if 
present in the request. 

A comma separates the URI query parameters from cookies. 
The square brackets in the rule indicate that the cookie 
5 is optional. If this cookie is not present, the rule can 
still succeed, and the cache ID will not include the 
cookie name-value pair. This allows the merchant to have 
a no-group price as well as a price per group. An 
example of the cache ID would be: 
10 http : / /www . acmes tore . com/productDesc . j sp_product ID=A 

N; T13394_groupID=*@#! 

□ Referring to Figure IID, an extension of the shopper 

P group scenario is provided. Support for multiple 

M merchants has been added; for example, an application 

Qfl5 service provider (ASP) supports multiple merchants in the 
f same Web application server using multiple languages, 

fll The parent product description fragment again contains a 

child price fragment. The parent is logically qualified 
O by productID, merchantID, and languagelD. The child is 

^ 20 logically qualified by productID, groupID, languagelD and 
merchantlD. The page URI has productID and merchantID 
query parameters. The request has userlD, groupID, and 
languagelD cookies. The languagelD cookie is created by 
the Web application during logon based on the user 
25 profile- The languagelD is made a cookie rather than a 
query parameter because it is used with every request, 
and it would be tedious for the Web application developer 
to put it in every link. 

The single cache ID rule for the parent fragment 
30 would use the URI path along with the productID and 

merchantID query parameters, and languagelD cookie, so it 
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can be cached with the correct qualifications. The 
parent cache ID rule would be : 

Fragment: cacheid='' (product ID merchantID, 
[languagelD] ) 

In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; 

(B) the name and value of the productID query 
parameter; 

(C) the name and value of the merchantID query- 
parameter ; and 

(D) the name and value of the languagelD cookie if 
present in the request. 

An example of the parent cache ID would be: 

http : / /www. acmeMall . com/productDesc • j sp_productID=AT 
133 94_merchantID=MyStore_languageID=eng 

The single cache ID rule for the child fragment 
would use the URI path along with productID and 
merchantID query parameters, and groupID and optional 
languagelD cookies, so it can be cached with the correct 
qualifications. The cache ID rule would be: 

Fragment: cacheid='' (productID merchantID, [groupID] 
[languagelD] ) " 

In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; 

(B) the name and value of the productID query 
parameter; 

(C) the name and value of the merchantID query 
parameter; 
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(D) the name and value of the groupID cookie if it 
is present in the request; and 

(E) the name and value of the languagelD cookie if 
it is present in the request. 

5 An example of the cache ID would be: 

http : / /www. acmeMall , com/productDesc . j sp_productID=AT 
13 3 94_merchant ID=MyStore__groupID=*@# ! _languageID=eng 

Referring to Figure HE, an extension to the ASP and 
multiple languages scenario is provided. Support has 
10 been added for multiple ways to identify products. The 
pi parent product description fragment contains a child 
C price fragment. The parent is logically qualified by 
jj product (there are two ways to specify this) , languagelD, 

;f and merchantlD. The child is logically qualified by 

Q|15 product, groupID, languagelD, and merchantlD. The 

product is identified either by the productID query 
ili parameter, or by partNumber and supplierNumber query 

parameters. The request has userlD, groupID, and 
languagelD cookies. The parent fragment would require 
20 two rules, which are specified as: 
Fragment : cacheid= 

(productID merchantlD, [languagelD] ) 
(partNumber supplierNumber merchantlD, 
[languagelD] ) " 

25 The first rule is tried. If it succeeds, then it 

determines the cache ID. If it fails, the second rule is 
tried. If the second rule succeeds, then it determines 
the cache ID. If it fails, the fragment is not cached. 
The first rule means that the cache ID is the following 

30 parts concatenated together: 
(A) the URI path; 
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(B) the name and value of the productID query 
parameter; 

(C) the name and value of the merchant ID query- 
parameter ; and 

5 (D) the name and value of the languagelD cookie if 

present in the request . 

An example of the cache ID for the first rule would be: 

http : //www. acmes tore • com/productDesc . j sp_j)roductID=A 
T133 94_merchantID=MyStore_languageID=eng 
10 The second rule means that the cache ID is the 

'^Zi following parts concatenated together: 

Q (A) the URI path; 

55 (B) the name and value of the partNumber query 

"^i parameter; 

ml5 (C) the name and value of the supplierNumber query 

: parameter; 

f|j (D) the name and value of the merchant ID query 

l^. parameter ; and 

Q (E) the name and value of the languagelD cookie if 

20 present in the request. 

An example of a cache ID for the second rule would be: 

http : //www. acmeStore . com/productDesc . j sp_partNumber= 
22 984 Z_suppl i erNumber = 3 3 900 l_mer chant ID=MyS t or e_l anguage I 
D=:eng 

25 The child fragment requires two rules, which are 

specified as follows: 

Fragment : cacheid= 

'MproductID merchantID, [groupID] [languagelD]) 
(partNumber supplierNumber merchantID, [groupID] 
30 [languagelD] ) 
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The first rule is tried. If it succeeds, then it 
determines the cache ID. If it fails, then the second 
rule is tried. If the second rule succeeds, then it 
determines the cache ID. If the second rule fails, the 
5 fragment is not cached. The first rule means that the 
cache ID is the following parts concatenated together: 

(A) the URI path; 

(B) the name and value of the product ID query 
parameter; 

10 (C) the name and value of the merchant ID query 

^ parameter; 

p (D) the name and value of the groupID cookie if it 

^f: is present in the request; and 

N (E) the name and value of the languagelD cookie if 

ml5 it is present in the request. 

^ An example of a cache ID for the first rule would be: 

flj http : //www. acmeStore . com/productDesc . j sp__productID=A 

T133 94_merchantID=MyStore_groupID=*@# !_languageID=eng 
C The second rule means that the cache ID is the 

20 following parts concatenated together: 

(A) the URI path; 

(B) the name and value of the partNumber query 
parameter; 

(C) the name and value of the supplierNumber query 
25 parameter; 

(D) the name and value of the merchantID query 
parameter; 

(E) the name and value of the groupID cookie; and 

(F) the name and value of the languagelD cookie. 
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An example of a cache ID for the second rule would be: 

http : //www. acmeStore . com/productDesc . j sp_partNuraber= 

22984Z_supplierNumber=339001_merchantID=iy[yStore_groupID=* 

@# !_language=eng 
5 Referring to Figure IIF, an extension to the product 

description scenario using personalization is provided. 

A parent product description fragment contains a child 

personalization fragment. The parent fragment is 

logically qualified by the productlD. The child fragment 
,J0 is logically qualified by the userlD, The page URI has a 
Cl productlD query parameter. The request has a userlD 
Q cookie. 

+ The parent cache ID includes the productlD query 

£ parameter. The cache ID rule for the parent fragment 

^^''15 would be either of the following two cases: 
F Fragment: cacheid=''URI'' 

In other words, the cache ID is the full URI with all 
query parameters. Another potential rule would be: 
P Fragment : cacheid=^ (product Id) " 

20 In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; and 

(B) the name and value of the productlD query 
parameter. 

25 It should be noted that even though the request for this 
page includes a userlD cookie, it is not included in the 
cache ID for either fragment because the fragment is 
product-specific and not user-specific. If it were 
included, then this fragment would only be accessible by 

30 that user, resulting in a larger cache and more work to 
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keep the cache updated. An example of a cache ID would 
be : 

http : //www . acmeStore . com/productDesc . j sp_productID=A 
T13394 

5 The child personalization fragment's cache ID 

includes a userlD cookie. The child fragment's cache ID 
rule would be : 

Fragment: cacheid='M, userld) " 
In other words, the cache ID is the following parts 
10 concatenated together: 

(A) the URI path; and 
rt (B) the name and value of the userlD cookie. 

An example of a cache ID would be: 
%! http : //www. acmeStore . com/personalization . j sp_userID= 

M5 ©($*!% 

J In this personalization example, the personalization 

n] fragments should be marked as private data, e.g., by 

[Z using ''Cache-Control: private". 

Q Referring to Figure 116, a parent stock watchlist 

20 fragment on a simple portal page contains multiple child 
stock quote fragments. The parent fragment also contains 
the user's name as a simple personalization. The parent 
is logically qualified by userlD, i.e. the list of stock 
symbols is user-specific. The user name is logically 
25 qualified by the userlD. Each child is logically 

qualified by its stock symbol, i.e. a stock's value is 
not user-specif ic . The page URI contains no query 
parameters. The request has a userlD cookie. 

The top-level fragment contains a required 
30 user-specific list of stock quotes. The top-level 
fragment's URI contains no query parameters. The 
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top-level fragment's cache ID includes an encrypted 
cookie named userlD. The cache ID rule would be: 

Fragment : cacheid=" ( , userld) " 
In other words, the cache ID is the following parts 
concatenated together: 

(A) the URI path; and 

(B) the name and value of the userlD cookie • 
An example of a cache ID would be: 

http : //www, acmelnvest . com/stockList . j sp_userID=@ ($* ! 

% 

For each of the stock quote fragments, the cache ID 
includes the ^'symbol" parameter. The cache ID rule would 
be the full URI or the URI path plus the stockSymbol 
query parameter: 

Fragment : cacheid= (stockSymbol ) " 
In other words, the cache ID is the following parts 
concatenated together : 

(A) the URI path; and 

(B) the name and value of the symbol query 
parameter . 

An example of a cache ID would be: 

http : //www . acmelnvest . com/stockQuote . j sp_stockSymbol 

=IBM 

This scenario can be modified to use the FOREACH 
feature; the stock quote fragments would not change, but 
the parent fragment can be highly optimized. There is 
only one static top-level fragment. A stockSymbols 
cookie would be used whose value is a blank- separated 
list of stock symbols for the user. There would be only 
one parent fragment for all users that is quite static, 
which contains a FRAGMENTLINK tag whose FOREACH attribute 
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would name the stockSymbols cookie. This dynamically 
generates a simple FRAGMENTLINK for each stock symbol 
whose SRC attribute is the same as the SRC of the 
FRAGMENTLINK containing the FOREACH attribute with the 
5 stock symbol added as a query parameter. Because this 
parent fragment is the same for all users, it can be 
cached with the correct qualifications with a single 
cache rule that uses its URI as the cache ID, which has 
no query parameters, as follow: 
10 Fragment : cacheid= "URI " 

!!: The StockSymbols cookie contains all the 

B user- specific information for the parent fragment and 
£; travels with the page request, so it satisfies the 

parent's logical userlD qualification. 
fljl5 A userName cookie whose value is the user's name 

would be used in a FRAGMENTLINK tag for the simple 
Ri personalization whose SRC attribute identifies the 
Ifv userName cookie. This fragment is not cached since it 
can easily be generated from the userName cookie. The 
20 userName cookie contains all the user- specif ic 

information for this fragment and travels with the page 
request, so it satisfies the parent's logical userlD 
qualification . 

The single cache ID rule for the child fragment uses its 
25 URI for the cache ID so that it can be cached with the 
correct qualifications, as follows : 
Fragment : cache id=^' URI" 

In this stock watchlist scenario, when the FOREACH 
feature is not being used, the top-level stock watchlist 
30 fragments would be marked private, e.g., by using 

''Cache-Control: private". When the FOREACH feature is 
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used, then there is only one top-level fragment that is 
shared; so it is not marked private. 

Referring to Figure IIH, the example depicts a 
scenario that is similar to a personalized portal page, 
5 such as myYahoo!. A first-level portal fragment contains 
multiple mid- level topic fragments, such as stocks, 
weather, sports, each of which contains multiple leaf 
item fragments. The parent fragment also contains the 
user's name. The top-level portal fragment is logically 
10 qualified by the userlD, i.e. the list of topics is 

user-specific. The user name is logically qualified by 
the userlD. The mid- level topics fragment is logically 
qualified by the topicID and userlD, i.e. the list of 
items in the topic is user-specific. The leaf item 
15 fragment is logically qualified by the itemID, i.e. an 

item's value is not user-specific. The page URI contains 
no query parameters . The page request has a userlD 
cookie. Through the use of the FOREACH feature, the 
parent fragment can be highly optimized. 
20 Using the FOREACH feature, a topics cookie (created 

during logon based on user profile) would be used whose 
value is a blank-separated list of topicIDs for that 
user. There would be only one parent fragment for all 
users that is quite static, containing a FRAGMENTLINK tag 
25 whose FOREACH attribute would name the topics cookie. 

This dynamically generates a simple FRAGMENTLINK for each 
topicID, whose SRC attribute is the same as the SRC of 
the FRAGMENTLINK containing the FOREACH attribute with 
the topicID appended as a query parameter. Because this 
30 parent fragment is the same for all users, it can be 
cached with the correct qualifications with a single 
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cache rule that uses its URI as the cache ID, which has 
no query parameters, as follows: 
Fragment : cache id= ''URI" 

The topics cookie contains all the user-specific 
5 information for the parent fragment and travels with the 
page request, so it satisfies the parent's logical userlD 
qualification. A userName cookie whose value is the 
user's name would be used in a FRAGMENTLINK for the 
simple personalization whose SRC attribute identifies the 
10 userName cookie. This fragment is not cached since it 
S can easily be generated from the userName cookie. The 
O- userName cookie contains all the user- specif ic 

J- information for this fragment and travels with the page 

'z request, so it satisfies the parent's logical userlD 

ttil5 qualification . 

There is a topic fragment for each topic. Because 
of the FOREACH feature, each of the topic fragments can 
^1 be highly optimized. For each topic, a cookie (created 
^: during logon based on user profile) would be used whose 

20 value is a blank-separated list of itemlDs for that user 
and topic. For each topic, there would be only one topic 
fragment for all users that is quite static containing a 
FRAGMENTLINK whose FOREACH attribute would name the 
corresponding cookie for that topic. This dynamically 
25 generates a simple FRAGMENTLINK for each itemID whose SRC 
attribute is the SRC of the FRAGMENTLINK containing the 
FOREACH attribute with the itemID added as a query 
parameter (the topicID query parameter is already there) . 
Because each topic fragment is the same for all users, it 
30 can be cached with the correct qualifications with a 
single cache rule that uses its URI as the cache ID, 
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which has its topicID as a query parameter. The topics 
cookie contains all the user- specif ic information for the 
topic fragment and travels with the page request, so it 
satisfies the topic fragment's logical userlD 
qualification. 

The URI for each item fragment contains its topicID 
and itemID as query parameters. The single cache ID rule 
for each item fragment uses its URI for the cache ID, so 
it can be cached with the correct qualifications. 

Examples for the Specification of FRAGMENTLINK Tags 

Referring again to the sidebar example in Figure 
llA, a single FRAGMENTLINK would be placed in the page 
instead of the sidebar and in the same location where the 
sidebar is desired, such as : 

{ f r agment 1 ink 
src="http : //www. acmes tore . com/ sidebar .html" } 

Referring again to the shopper group example in 
Figure IIC, a single FRAGMENTLINK would be located where 
the price would be, such as: 

{ fragment link 
src="http : / / www . acmeStore . com/productPrice . j sp" } 

The URI that is constructed for a particular price 
fragment would look as follows: 

http : //www. acmeStore . com/productPrice . j sp?productID= 
AT13394 

The request for the fragment includes all of the 
parent's query parameters, i.e. ^^productld" , and cookies, 
i.e. '"groupld" , so that they are available during the 
execution of productPrice . j sp in the application server. 
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Referring again to the personalization example in 
Figure IIP, the top-level fragment would include a 
FRAGMENTLINK located where the personalized fragment is 
desired, such as: 
5 {fragment link 

src="http : //www. acmeStore . com/personalization . j sp'' } 
The URI that is constructed for a particular 
user-specific personalization fragment would look like as 
follows : 

10 http : //www. acmeStore . com/personalization* j sp?product 

g ID=AT13 3 94 

0 The request for the fragment includes all of the 

£ parent's query parameters (ie, ''productid" ) and cookies 

1 He, ^^userld") . During the execution of 

CSil5 personalization, j sp, the '"userld" cookie is used but the 
""productld" query parameter is ignored. 

Referring again to the stock watchlist example in 
JJ: Figure IIG, the top-level fragment would include a 

variable number of FRAGMENTLINK tags that depends on how 
20 many stock quotes that the user wanted. Each 

FRAGMENTLINK tag would be located where the stock quotes 
would be. Each would look as follows: 
{ f r agment 1 ink 

src="http : / /www . acmelnvest . com/ stockQuote . j sp? symbol 
25 =IBM"} 

The URI that is constructed for a particular stock 

quote fragment would look as follows: 

http : //www . acmelnvest . com/stockQuote . j sp?symbol=IBM 
This scenario can be modified to use the FOREACH 
30 feature; the variable number of FRAGMENTLINK tags are 

replaced by a single FRAGMENTLINK tag with the FOREACH 
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attribute specifying the name of a cookie (stocks) whose 
value is a blank- separated list of stock symbol 
parameters : 

{ fragment link 

src="http : //www. acmelnvest . com/stockQuote . j sp" 
f oreach= " stocks " } 

If the value of the cookie named ''stocks" was 
symbol=IBM symbol=CSCO symbol=DELL 
then this would be equivalent to the following set of 
FRAGMENTLINK tags: 
{f ragmentlink 
src="http : / /www. acmelnvest . com/ stockQuote . j sp?symbo 
1=IBM"} 

{ f ragmentlink 
src = "http : //www , acmelnvest . com/ stockQuote . j sp?symbo 
1=CSC0'' } 

{f ragmentlink 

src="http : / /www . acmelnvest . com/ stockQuote . j spPsymbo 
1=DELL"} 

Referring again to the full portal example in Figure 
IIH, the FOREACH feature can be used for a single static 
top-level fragment that would be shared by all users. 
The userName in the top-level fragment would be included 
using the following FRAGMENTLINK that identifies the 
userName cookie, which contains the user's name: 
{f ragmentlink src=" cookie : //userName" } 
The top-level fragment would also have a 
FRAGMENTLINK tag whose FOREACH attribute identifies the 
topics cookie, which contains that user's list of topics: 
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{fragment link 

src="http : //www. acmePortal . com/portalPage . j sp" 
foreach=" topics" } 

This cookie contains a list of topicIDs. For a 
topics cookie whose value is the following: 

topic=stocks topic=weather topic=tv 
the above FRAGMENTLINK containing the FOREACH attribute 
would generate the following simple FRAGMENTLINKS : 

{f ragmentlink 

src="http : //www . acmePortal . com/portalPage . j sp?topic 
stocks" } 

{f ragmentlink 

src="http : //www. acmePortal . com/portalPage . j sp?topic 
weather" } 

{ f ragmentlink 

src="http : //www. acmePortal . com/portalPage . j spPtopic 

tv"} 

Each of the dynamically generated SRC attributes 
locates a fragment that handles the specified topic. 

The implementation of ''portalPage . j sp" in the Web 
application server acts as a dispatcher that calls a 
fragment based on the query parameters. No parameter 
returns the top-level fragment. A ''topic=stocks" query 
parameter returns the stocks topic fragment. Using the 
stocks topic fragment as an example, and again using the 
FOREACH feature, the stocks topic fragment contains a 
FRAGMENTLINK whose FOREACH attribute identifies a stocks 
cookie, which contains that user's list of stock symbols 
for that topic: 
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{f ragmentlink 
src="http : //www. stockQuotes . com/stockQuote . j sp" 
foreach=" stocks" } 
An exemplary use of this would be to generate rows of a 
5 table with a row for each stock symbol in the stocks 
cookie. For a ''stocks" cookie whose value is 

symbol=IBM symbol=DELL symbol=CSCO 
the above FRAGMENTLINK containing the FOREACH attribute 
would dynamically generate the following FRAGMENTLINKS : 
10 { f ragmentlink 

src="http : / /www. StockQuotes . com/stockQuote , j sp?symbo 
ri 1=IBM"} 

w 

3 {f ragmentlink 

':f src="http : //www. stockQuotes . com/stockQuote . j sp?symbo 

Hil5 1=DELL'' } 

r { f ragment 1 ink 

fli src=''http : //www. StockQuotes . com/stockQuote . j sp?symbo 

J 1=0500" } 

20 Examples of Passing Data From Parent Fragment to 
Child Fragment 

A fragment should be as self-contained as possible. 
There are two reasons for this. The first reason is that 

25 good software engineering dictates that software modules 
should be as independent as possible. The number and 
complexity of contracts between modules should be 
minimized, so that changes in one module are kept local 
and do not propagate into other modules. For example, an 

30 application might get data in a parent module and pass 

this data into a child module that formats it. When this 
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is done, there has to be a contract describing what the 
data is and how it is to be passed in. Any change in 
what data is needed by the child module requires changes 
to both modules. Instead, if the child module gets its 
5 own data, then the change is kept local. If there is a 
need to make either module independent of how its data is 
obtained, or the code that obtains its data is the same 
in several modules, then a separate data bean and a 
corresponding contract can be used to accomplish either 
10 of these requirements. However, adding yet another 
M contract between the parent and child modules is only 

S added complexity without accomplishing anything. 

W The second reason that a fragment should be as 

4] self-contained as possible is that to make caching 

2:15 efficient, the code that generates a fragment should be 
3 self-contained. In the above example, if the parent 

m module gets all the data for the child module and passes 

it into the child, then the child itself only does 
g formatting. With this dependency between modules, if the 
""'20 data needed by the child module becomes out of date, then 
both the parent and child have to be invalidated and 
generated again. This dependency makes caching of the 
separate fragments much less effective. A fragment that 
is shared by multiple parents complicates both of the 
25 above problems . 

The JSP programming model allows data to be passed 
between JSPs via request attributes or session state. 
For nested fragments, the request attribute mechanism 
does not work because the parent and child JSPs may be 
30 retrieved in different requests to the application 

server. Also, the session state mechanism may not work 
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if the parent and child can be executed in different 
sessions. Instead, any information that should be passed 
should use URI query parameters or cookies. Even a 
complex data structure that was passed from parent to 
5 child using request attributes could still be passed by 
serializing it and including it as a query parameter in 
the URI in the FRAGMENTLINK tag's SRC attribute. 

Even when fragments get their own data, there is 
still a need to pass some control data between them. 
10 Referring to the above examples again, in the sidebar 
u scenario, no data is passed from the top-level fragments 

to the sidebar. In the shopper group scenario, the 
W top-level product -description fragment needs to know the 
Ti product ID, and the child group-product specific price 

J;15 needs both the product ID and the shopper group ID. The 
s product ID is supplied by the external request- The 

JJ; shopper group ID is generated by the application using 

M the user ID, both of which are generated at logon. Both 

5 the product ID and the shopper group ID should be passed 
^2S) through the product description fragment to the price 
fragment. All URI query parameters and cookies are 
automatically passed to the child fragment. 

In the personalization scenario, the top-level 
product description fragment needs to know the product 
25 ID, and the child personalization fragment needs to know 
the user ID. Both of these parameters are supplied by 
the external request, so the user ID should be passed 
through the product description fragment to the 
personalization fragment. This is done by passing the 
30 cookie named ''userld" on to the child fragment. 
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In the stock watchlist scenario, the top-level stock 
watchlist fragment needs to know the user ID cookie, and 
each of the child stock quote fragments need to know the 
stock symbol. The stock symbols and the FRAGMENTLINK 
5 tags that contain them are generated as part of the 
top-level stock watchlist fragment. The stock symbol 
should be passed to the stock quote fragment. This is 
done by putting the stock symbol as a query parameter of 
the URI in the SRC attribute of the FRAGMENTLINK. 

10 

Examples of FRAGMENTLINK tags and FRAGMENT headers 

With reference now to Tables lA-lC, a set of HTML 
4; and HTTP statements are shown for the sidebar example 
j;15 discussed above. Both fragments within this scenario are 

static. The parent top-level fragment would be a JSP 
H because it contains another fragment using a 
yj ^jsp: include" and because cache control information needs 
^ to be associated with the parent fragment. The child 

p20 sidebar fragment is also a JSP because caching control 

information needs to be associated with it, but it does 

not contain any JSP tags . 
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Table lA shows a JSP including HTML statements for 
the top-level fragment that contains the sidebar 
fragment , 



5 {html} 
{head} 

{titlejA page containing a side bar. {/title} 
{/head} 
{body} 

10 {i-- Add the side bar. --} 

{ j sp : include page= " /sidebar . html " } 
{p}This is the rest of the body. 

{/body} 

{/html} 



TABLE lA 
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Table IB shows the HTTP output that would be 
generated by a Web application server for the top-level 
fragment . 



5 HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 . 6 . 2 Apache/1 . 3 . 7-dev (Unix) 

Last -Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 
10 Accept - Ranges : bytes 

Content - Length : 246 

Content -Type : text /html 

Cache - Control : no-cache fragment rules 

Pragma: no- cache 
15 Fragment: cacheid="URL" 
H Cache -Control : max-age=600 

Q Fragment: contains -fragments 

kj {html} 

=120 {head} 

%1 {title}A page containing a side bar. {/title} 

£ {/head} 

m {body} 

I^- {%-- Add the side bar --%} 

Lis^S { fragment link src= "http : / /www . acmeStore . com/ sidebar . html " } 

iZ ... This is the rest of the body . . . 

% {/body} 
230 {/html} 



TABLE IB 



35 
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Table IC shows the HTTP output that would be 
generated by a Web application server for the sidebar 
fragment . 



5 HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 . 6 . 2 Apache/1 .3 . 7-dev (Unix) 

Last-Modif ied: Wed, 11 Apr 2001 21:05:09 GMT 

ETag : " b 7 - d8 d - 3 ad4 c 7 0 5 " 
10 Accept -Ranges: bytes 

Content -Length: 82 

Content-Type: text/html 

Cache -Control : no-cache f ragmentrules 

Pragma: no -cache 
15 Fragment: c ache id= "URL" 
M Cache-Control: max-age=6000 

5 {html} 
y {body} 

j20 {p}This is the side bar body, 

{/body} 
r-' {/html} 



TABLE IC 
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With reference now to Tables 2A-2D, a set of HTML 
and HTTP statements are shown for the shopper group 
example discussed above. Both fragments within this 
scenario are dynamic. A JSP is used for the top-level 
5 fragment that contains the product -group- specif ic price 
fragment. The child fragment is also a JSP because it 
contains business application logic for obtaining the 
appropriate price. 

Table 2A shows a JSP containing HTML statements for 
10 the top-level product description fragment that contains 
the child fragment. 



{html} 
{head} 

15 {title} Product description. { /title} 

{/head} 
{body} 

{hi} Product with Shopper Group, {/hi} 
{%@ page language^" java" 
20 import = " com . acmeStore . databeans . * " 

%} 

{% 

// Add the product description. 

ProductSGDataBean databean = new ProductSGDataBean ( ) ; 
25 databean.setProductId(request.getParameter( "product Id") ) ; 

databean . execute ( ) ; 

out .printlnC" {p} Product id is " + databean.getProductldO ) ; 

%} 

{%-- Add the price --%} 
30 {jsp: include page="/groupPrice . j sp" } 

{/body} 
{/html} 



35 
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Table 2B shows the HTTP output that would be 
generated by a Web application server for the product 
description fragment. 



5 HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP__Server/l . 3 . 6 . 2 Apache/1 . 3 . 7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 
10 Accept -Ranges : bytes 

Content - Length : 8 2 

Content -Type : text /html 

Cache -Control : no-cache f ragmentrules 

Pragma: no -cache 
15 Fragment: cacheid=" (product Id) " 
f^^ Cache - Control : max-age=600 

D Fragment: contains -fragments 

W {html} 
£20 {head} 

%i {title}Product description. {/title} 

£ {/head} 
Sj {body} 

2 {hi} Product with Shopper Group, {/hi} 

yj,25 ...The formatted product descriptions would be here... 

f|i { fragment link src="http : / /www. acmeS tore . com/groupPrice . j sp" } 

{/body} 

{ /html } 

S3O ~~ 

TABLE 2B 
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Table 2C shows a JSP containing HTML statements for 
the child product -group -specific price fragment. 



{html} 
5 {body} 

{%® page language=" java" 

import = "com. acmeStore.databeans . *" %} 
{% // Get the groupid from its cookie. 

Cookie [] cookies = request .getCookies () ; 
10 String groupid = null; 

for (int i = 0; i { cookies . length; i++) { 

if (cookies [i] .getName {) .equals ("groupid") ) { 
groupid = cookies [i] .getValue () ; 

} 

15 } 

II Get the price. 

GroupPriceDataBean databean = new GroupPriceDataBean () ; 
^: databean . setGroupId (groupid) ; 

databean , execute ( ) ; 
^ff20 string price = databean.getPriceO ; 

out .println("{p}Price is " + price); %} 
^ {/body} 
4^ {/html} 



^25 
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Table 2D shows the HTTP output that would be 
generated by a Web application server for the 
product-group-specific price fragment. 



5 HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 . 6 .2 Apache/1 . 3 . 7-dev (Unix) 

Last -Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 
10 Accept-Ranges: bytes 

Content -Length: 82 

Content -Type : text /html 

Cache- Control : private 

Cache - Control : no-cache f ragtnentrules 
15 Pragma: no- cache 

Fragment: cacheid=" (product Id, group Id) " 

Fragment : dependencies ="http : //www. acmeStore . com_groupid=*®# ! " 

Q {html} 

W20 {body} 

i Price is $24.99 

%l {/body} 

=P {/html} 

25 

TABLE 2D 
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With reference now to Tables 3A-3D, a set of HTML 
and HTTP statements are shown for the personalization 
example discussed above. Both fragments within this 
scenario are dynamic. A JSP that generates the top-level 
5 product fragment contains a single user- specif ic 

personalization fragment. The child fragment is also a 
JSP because it contains business application logic for 
obtaining the appropriate personalization data for the 
user. 

10 Table 3A shows a JSP containing HTML statements for 

the top-level product description fragment that contains 
I the child fragment. 



2: {html} 

JU5 {head} 

2 {title} Product description. {/title} 

£ {/head} 

^ {body} 

^ {%@ page language=" java" 

^^"20 imports "com, acmes tore . databeans . * , com. acmeStore . formatters . * " 

m %} 

H= {% 

y,J; // Add the product description. 

C| ProductDataBean databean = new ProductDataBeanO ; 

M^25 databean. setProductId (request .getParameter{"productId") ) ; 

databean . execute 0 ; 

ProductFormatter productFormatter = new ProductFormatterO ; 
out .print In (productFormatter . format (databean) ) ; 

%} 

30 {%-- Add the personalization --%} 

{ j sp : inc lude page= " /per sonal i zat ion . j sp " } 

{/body} 

{/html} 



35 

TABLE 3A 



AUS920010792US1 

144 

Table 3B shows the HTTP output that would be 
generated by a Web application server for the product 
description fragment. 

5 HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 . 6 .2 Apache/1 . 3 . 7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 
10 Accept -Ranges : bytes 

Content -Length: 82 

Cont ent - Type : t ext / html 

Cache-Control: no-cache f ragmentrules 

Pragma : no - c a che 
^„15 Fragment: cacheid=" (product Id) " 
L,, Cache - Control : max-age=600 

Fragment : contains - fragments 

W {html} 

4^0 {head} 

2 {title} Product description. {/title} 

4=; {/head} 

81 {body} 

s {hi} Product with Shopper Group, {/hi} 

1^25 . . . The formatted product descriptions would be here . . . 

Oj { fragment link src= "http : //www , acmeStore . com/personalization . j sp" } 

{/body} 

tfl {/html} 



1-30 
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Table 3C shows a JSP containing HTML statements for 
the child user-specific fragment. 



{html} 
{body} 

{%® page language=" java" 

imports " com . acmeStore . dat abeans . * " % } 
{% // Get the userld from the userld cookie. 

Cookie [] cookies = request .get Cookies () ; 

String userld = null; 

for (int i - 0; i { cookies . length; i++) { 

if (cookies [i] .getNameO . equals ( "userld" ) ) { 
userld = cookies [i] .getValue () ; } } 

"dependencies=\ "http : //www. acmeStore . com/userId=@ ($* I %\ " " ) ; 

response. addHeader ("Fragment", "cacheid=\" (, userld) \"") ; 

// this one depends on userld: 

response . addHeader ( " Fragment " / 

" dependenc i e s = \ " ht tp : / /www . acmeStore . com/user I d= " + 
userld + "\"") ; 

// Create the personalization. 

PersonalizationDataBean databean = 

new PersonalizationDataBean 0 ; 

databean. setUserld (userld) ; 

databean . execute ( ) ; 

String personalization = databean. getPersonal ization () ; 

out .println (personalization) ; %} 
{/body} 
{/html} 
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Table 3D shows the HTTP output that would be 
generated by a Web application server for the child 
fragment . 



5 HTTP/1.1 200 OK 

Date: Moil; 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 • 6 . 2 Apache/1.3 .7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 
10 Accept -Ranges : bytes 

Content - Length : 8 2 

Content - Type : text /html 

Cache - Cent rol : private 

Cache - Control : no-cache fragment rules 
15 Pragma: no- cache 
1^, Fragment: cacheid="(, userld) " 

%l Fragment : dependencies="http : //www.acmeStore . com_userId=® {$* I %" 

H {html} 
^j20 {body} 

"t- . . . The personalization would be here . . . 

{/body} 
2;: {/html} 



f.25 
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With reference now to Tables 4A-4P, a set of HTML 
and HTTP statements are shown for the stock watchlist 
example discussed above. Both fragments within this 
scenario are dynamic. 

5 Table 4A shows a JSP that generates the top-level 

stock watchlist fragment that contains multiple stock 
quote fragments. The ''j spext : cookie" tag displays the 
user name that is in a cookie named ''userName" . This 
example dynamically generates a variable number of 

10 ''RequestDispatcher. include" method invocations, each 
generating a FRAGMENTLINK tag in the output. 



AUS920010792US1 

148 



{html} 
{head} 

{title}Stock watch list . {/title} 
{/head} 

{body} 

{%@ page language=" java" 

imports " com . acmelnvest . databeans . * " 

%} 
{% 

// Get the userld from the userld cookie. 
Cookie [] cookies = request .getCookies () ; 
String userld = null; 

for (int i = 0; i { cookies . length; i++) { 

if (cookies [i] .getNameO . equals ( "userld" ) ) { 
userld = cookies [i] .getValue () ; 

} 

} 

%} 

{table border} 
{tr} 

{th colspan=2 align=center} 

{jspext: cookie natne="userName" } ' s Stock Watch List: 
{/th} 

{/tr} 

{tr} 

{th align=center} Symbol {/th} 
{th align=center} Price {/th} 

{/tr} 

{% 

// Add the stock watch list rows to the table. 
StockListDataBean databean = new StockListDataBeanO ; 
databean.setUserld (userld) ; 
databean . execute ( ) ; 

String [] symbols = databean. getStockSymbolList () ; 
for (int i = 0; i { symbols . length; i++) { 

String url = "/stockQuote. jsp?stockSymbol=" + symbols [i] ; 

ServletContext servlet Context = getServletContext () ; 

RequestDispatcher requestDispatcher = 

ServletContext . getRequestDispatcher ( " /stockQuote . j sp" ) ; 
requestDispatcher . include (request, response) ; 

} 

{/table} 

{/body} 

{/html} 



TABLE 4A 
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Table 4B shows the HTTP output that would be 
generated by a Web application server for the stock 
watchlist fragment . 



HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/l . 3 . 6 , 2 Apache/1 . 3 . 7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag : "b7-d8d-3 ad4 c 7 0 5 " 

Accept -Ranges : bytes 

Cont ent - Length : 8 2 

Content - Type : text /html 

Cache-Control : private 

Cache - Control : no-cache fragment rules 

Pragma : no - cache 

Fragment: cacheid="(, userld) " 

Fragment : contains -fragments 

{html} 
{body} 

{table border} 
{tr} 

{th colspan=2 align=center } 

{fragmentlink src= "cookie : //userName" }' s Stock Watch List: 

{/th} 

{/tr} 
{tr} 

{th align=center} Symbol {/th} 
{th align=center}Price{/th} 

{/tr} 

{fragmentlink 

src="http : //www. acme Invest . com/stockQuote . j sp?symbol=IBM" } 
{fragmentlink 

src="http : //www. acmelnvest . com/stockQuote . j sp?syrabol=CSCO" } 

{fragmentlink 

src= "http : //www. acmelnvest . com/stockQuote . j sp?symbol=DELL" } 
{/table} 
{/body} 
{/html} 
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Table 4C shows a JSP that generates the top-level 
stock watchlist fragment that incorporates a FOREACH 
attribute . 

5 {html} 
{head} 

{title}Stock watch list . {/title} 



10 



{/head} 
{body} 
{%® page 



languages " j ava " 

import = " com . acmelnves t . databeans . * " % } 



15 




{/tr} 
{tr} 



20 



{th align=center} Symbol {/th} 
{th align=center} Price {/th} 

{/tr} 

{jspext: include page="/stockQuote. jsp" foreach=" stocks"} 



25 



{/table} 

{/body} 

{/html} 
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Table 4D shows the HTTP output that would be 
generated by a Web application server for the top-level 
stock watchlist fragment that incorporates a FOREACH 
attribute • 

5 

HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM__HTTP_Server/l .3 . 6 .2 Apache/1. 3. 7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 
10 ETag: "b7-d8d-3ad4c705 " 

Accept-Ranges : bytes 

Content -Length : 246 

Content -Type : text /html 

Cache - Control : no-cache f ragmentrules 
N^-.15 Pragma: no-cache 
O Fragment: contains -fragments 

Fragment : cacheid= "URL" 
y^l Cache - Control : max-age=600 

Hi 20 {html} 
{head} 

gf {title}Stock watch list . {/title} 

7' {/head} 

y, {body} 

^=25 {table border} 

li. {tr} 

"si {th colspan=2 align=center} 

'f: {fragmentlink src="cookie : //userName" } ' s Stock Watch List: 

H {/th} 

^^30 {/tr} 

{tr} 

{th align=center} Symbol {/th} 
{th align=center} Price {/th} 

{/tr} 

35 {fragmentlink 

src="http : //www. acmelnvest . com/stockQuote . j sp" 
f oreach= " stocks " } 

{/table} 
{/body} 
40 {/html} 
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Table 4E shows a JSP that generates the individual 
stock quote. 



{html} 
{body} 

{%@ page language=" java" 

import = " com . acmelnvest . databeans . * " 

%} 
{% 

// Add the stock quote. 

StockQuoteDataBean databean = new StockQuoteDataBeanO ; 
String symbol = request .get Parameter ( "symbol" ) ; 
databean. setStockSymbol (symbol) ; 
databean . execute ( ) ; 

String quote = databean. getStockQuote () ; 
String rtn = 

"{tr}" + 

"{td align=center} " + symbol + "{/td}" + 
"{td align=right} " + quote + "{/td}" + 
"{/tr}"; 
out .println(rtn) ; 

%} 

{/body} 
{/html} 
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Table 4P shows the HTTP output that would be 
generated by a Web application server for a symbol query 
parameter "IBM". 



HTTP/1.1 200 OK 

Date: Mon, 23 Apr 2002 17:04:04 GMT 

Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3 .7-dev (Unix) 

Last-Modified: Wed, 11 Apr 2001 21:05:09 GMT 

ETag: "b7-d8d-3ad4c705 " 

Accept-Ranges : bytes 

Content -Length : 82 

Content -Type : text /html 

Cache- Control : private 

Cache - Control : no-cache f ragmentrules 

Pragma : no - c ache 

Fragment : cacheid=" ( , userld) " 

Cache- Control : max-age=1200 

{html} 
{body} 
{tr} 

{td align=center}lBM{/td} 

{td align=right}$112 .72{/td} 
{/tr} 
{/body} 
{/html} 
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The advantages of the present invention should be 
apparent in view of the detailed description of the 

5 invention that is provided above. A fragment caching 
technique can be implemented within a cache management 
unit that may be deployed in computing devices throughout 
a network such that the cache management units provide a 
distributed fragment caching mechanism* 

10 A FRAGMENT header is defined to be used within a 

network protocol, such as HTTP; the header associates 
metadata with a fragment for various purposes related to 
the processing and caching of a fragment. For example, 
the header is used to identify whether either the client, 

15 server, or some intermediate cache has page assembly 

abilities. The header also specifies cache ID rules for 
forming a cache identifier for a fragment; these rules 
may be based on a URI for the fragment, or the URI path 
and some combination of the query parameters from the 

20 URI, and cookies that accompany the request. In 
addition, the header can specify the dependency 
relationships of fragments in support of host-initiated 
invalidations • 

The FRAGMENTLINK tag is used to specify the location 

25 in a page for an included fragment which is to be 

inserted during page assembly or page rendering. A 
FRAGMENTLINK tag is defined to contain enough information 
to either find the linked fragment in a cache or to 
retrieve it from a server. Cache ID rules are used both 

30 when a fragment is being stored in the cache and when 

processing a source identifier from a request to find the 
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fragment within a cache. To find the fragment in the 
cache, the cache ID rules that are associated with the 
fragment's URI path are used to determine the cache ID. 
The rules allow a high degree of flexibility in forming a 
cache ID for a fragment without having to deploy a 
computer program that forces a standard implementation 
for cache ID formation. Multiple cache ID rules may be 
used. The cache ID rules allow a cache ID to be a full 
URI for a fragment or the URI and a combination of query 
parameters or cookies. This scheme allows the same 
FRAGMENTLINK to locate different fragments depending on 
the parent fragment's query parameters and cookies; for 
example, a user ID cookie in the request for a product 
description page could be used to form the cache ID for a 
personalization fragment. 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system, those of ordinary 
skill in the art will appreciate that some of the 
processes associated with the present invention are 
capable of being distributed in the form of instructions 
in a computer readable medium and a variety of other 
forms, regardless of the particular type of signal 
bearing media actually used to carry out the 
distribution. Examples of computer readable media 
include media such as EPROM, ROM, tape, paper, floppy 
disc, hard disk drive, RAM, and CD-ROMs and 
transmission- type media, such as digital and analog 
communications links. 

The description of the present invention has been 
presented for purposes of illustration but is not 
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intended to be exhaustive or limited to the disclosed 
embodiments. Many modifications and variations will be 
apparent to those of ordinary skill in the art. The 
embodiments were chosen to explain the principles of the 
invention and its practical applications and to enable 
others of ordinary skill in the art to understand the 
invention in order to implement various embodiments with 
various modifications as might be suited to other 
contemplated uses. 



